Security Certificates

"Three may keep a secret, if two of them are dead."

famously said Benjamin Franklin. We may smile at Mr. Franklin's penchant for the theatrical, and admire at the gothic fantasies inspired by the notion of secrets, but in the modern digital world, the business of keeping secrets is a much less Shakespearian one.

The exact science behind modern cryptography is beyond the scope of this tutorial, suffice to know, that sometime between the death of Jimi Hendrix and the rise of Margaret Thatcher, computer scientists mixed a few prime numbers with a dash of mathematical magic, and out came Asymmetric key algorithms.

And the Public-Key Cryptography is a methodology that uses asymmetric key algorithms to protect communications or authenticate messages. The concept of asymmetric keys has done away with the requirement of a secure initial exchange of one or more secret keys as is required when using symmetric key algorithms.

Lying at the heart of the Public-Key Cryptography is two sets of numbers, the public key and the private key. Both the public and the private keys are needed for encryption /decryption but only the owner of a private key ever needs to know it. Using this system, the private key never needs to be sent across the Internet.

The private key is used to decrypt text that has been encrypted with the public key. Thus, if I send you a message, I can find out your public key (but not your private key) from a central administrator and encrypt a message to you using your public key. When you receive it, you decrypt it with your private key. In addition to encrypting messages (which ensures privacy), you can authenticate yourself to me (so I know that it is really you who sent the message) by using your private key to encrypt a digital certificate. When I receive it, I can use your public key to decrypt it.

Certificates

In practice, secure messages being passed between computers rely on Certificates. Electronic documents which contain digital signatures to bind together digital keys with an identity ù information such as the name of a person or an organization, their address, and so forth.

And Email security is based on digital signatures, encryption and decryption of messages through the use of certificates.

S/MIME

eM Client uses the Secure / Multipurpose Internet Mail Extensions or S/MIME standard for public key encryption and signing of e-mails.

Before S/MIME can be used, one must obtain and install an individual key/certificate either from one's in-house certificate authority (CA) or from a public CA such as one of those listed below. Best practice is to use separate private keys (and associated certificates) for Signature and for Encryption, as this permits escrow of the encryption key without compromise to the non-repudiation property of the signature key. Encryption requires having the destination party's certificate on store (which is typically automatic upon receiving a message from the party with a valid signing certificate). While it is technically possible to send a message encrypted (using the destination party certificate) without having one's own certificate to digitally sign, in practice, the S/MIME clients will require you install your own certificate before they allow encrypting to others. A typical basic personal certificate verifies the owner's identity only in terms of binding them to an email address and does not verify the person's name or business. The latter, if needed (e.g. for signing contracts), can be obtained through CAs that offer further verification (digital notary) services or managed Public Key Infrastructure service. Depending on the policy of the CA, your certificate and all its contents may be posted publicly for reference and verification. This makes your name and email address available for all to see and possibly search for. Other CAs only post serial numbers and revocation status, which does not include any of the personal information. The latter, at a minimum, is mandatory to uphold the integrity of the public key infrastructure.